複習一下之前討論過的，均一目前的資料架構跟服務，在 dbt 與 BigQuery 的轉換、運算與儲存之後，下游有幾個不同情境的運用，其中最大宗的運用即是我們的視覺化與報表工具 —— Metabase。

Metabase 這個工具也是由資料部門來維運，比起其他 fancy 的視覺化工具，可能有更多圖種可以選，更多的操作方法等等，選擇這個工具主要是因為他仍是一個 SQL-based 的視覺化工具，統一都使用 SQL 來維運，對工程師們來說比較單純方便，而視覺化的處理目前也都尚能滿足需求端。

BigQuery, dbt, Metabase，每多一種工具，在串接上就要做更多的思考。

在導入 dbt 的同時，我們也希望能加強與下游的整合。

當我們接手這個資料服務時，Ｍetabase 就已經有堆積如山的儀表板跟各種查詢，我們無從得知這些內容是為了什麼目的而建、是否還有人在關注。

而當我們改用 dbt 在建立資料模型時，我們就與各組多次同步，同時比對 Metabase 提供關於使用紀錄的 Metadata，確認哪些內容仍被使用，將比較常用的儀表板更新為 dbt 所建立的資料表，將其納入管轄區內。

終於要提到之前說過關於用 git diff 判斷有異動的資料模型的好處！

我們用 git diff 取得異動資料模型的清單後，除了用來做為需要更新的資料模型依據之外，我們同時將其作為變數傳入對於 Metabase 儀表板的查詢中，取得那些 query 中有使用這些資料模型的儀表板。

select
	card_id,
	card_name,
	card_link,
from `metabase_query_logs`
where query like "%{model_name}%"

取得結果之後，就用 GitHub Script（link）的工具，在 PR 建立時，把這些儀表板作為 PR comment 呈現出來。

完成了這些工作之後，每當有人建立 PR 時，自動化工具會將有相關的 Metabase 儀表板呈現於 comment 中，開發者以及審查者均可以直接透過其中的連結直接確認儀表板是否有需要做相對應的調整，不用擔心資料的脫節、使用者沒有發現錯誤一直使用等等的情況發生！